Active Directory資産を活用したAWS Management ConsoleへのSSO
はじめに
藤本です。
みなさん、AWS Management Consoleのアカウント管理はどうされていますか? AWSにおけるアカウント管理は多数存在し、その中でもManagement Consoleへのログインに関するアカウント管理も多数存在し、何を選択するのがベストなのか判断が難しいところです。 今回はWindows ServerのActive Directoryと連携し、Management Consoleへシングルサインオンする方式をご紹介します。
この方式を利用することで得られるメリットは多くあります。
【利用者】
- 新たなアカウントを管理する必要がない Active Directoryのアカウントのみを管理していればよく、新たなアカウントID、パスワードを管理する必要がない。
【管理者】
- 既存のActive Directory資産を利用可能 既に社内でActive Directoryによってアカウント管理されている企業はアカウント情報をそのまま利用できます。
-
IAMユーザーの個別管理不要 認証をActive Direcotryに委任することでManagement Consoleのアカウント管理から開放されます。社員入社時のアカウント追加、部署異動時の権限変更、社員退職時アカウント削除を全てActive Directoryだけで行うことができます。
-
グループによる権限管理でもアカウントの特定が可能 現在のアカウント管理は「誰が」、「いつ」、「何に対して」、「何を」行ったのか、トレースできる仕組みを導入することが一般的です。複数人で一つのアカウントを使い回すのではなく、個別アカウントの管理が必要です。上記のグループによる個別管理不要の仕組みを考える場合、「誰が」を追うことができなくなりがちです。AWSでトレースの仕組みとしてCloudTrailがありますが、今回ご紹介する方式はADアカウントの任意の情報をAWSに渡すことによりアカウントを特定したトレースを行うができます。ここは「動作確認」の章で説明します。
-
アカウント乗っ取りの回避 イントラネット内のActive Directoryに認証することで、誰でもアクセス可能なパブリッククラウドのリスクでもあるユーザーID・パスワード漏洩によるアカウントの乗っ取りのリスクも回避することができます。
-
既存環境の設定変更が最小限(ADアカウントへのグループ追加のみ) 今回ご紹介する方法は既存Active Direcotryの設定をほぼ変更することなく、実現可能なため導入のリスクが限りなく少ないです。ADFSはAcitive Directoryと同居させても問題ないですが、Active Directoryへの変更リスクを考慮すると、新規で立てる方がよいように思えます。サーバ購入手配の方がハードルが高いようでしたら同居を選ぶこともありかと思います。
いかがでしょうか? アカウント管理者、セキュリティ担当者は導入を考えたくなるのではないでしょうか?
概要
この方式はオンプレミスのActive Direcotry Federation Services 2.0(以下、ADFS)をSAMLのIdentity Provider(以下、IdP)として導入し、AWSとSAML認証することでSSOを実現します。Active Directoryのアカウント情報からIAM RoleへAssumeRoleすることでAWS Management Consoleの権限を得ることができます。
今回の設定例ではActive Directoryのアカウントが属するグループ名とIAM Roleをマッピングしています。 例えば、AというADアカウントを「AWS-developer」グループに所属させることでIAM Roleの「ADFS-devoloper」としてログインすることができます。
この方式は公式ドキュメントが大変わかり易いので、ご参照いただければと思います。 SAML を使用してフェデレーティッドユーザーに AWS コンソールへのアクセスを許可する
設定の流れは以下となります。
- ADFSインストール
- ADFS初期設定
- ADFSメタデータ取得
- AWSへIdP登録(SAML2.0認証用)
- IAM Role作成(AssumeRoleWithSAML)
- ADFS信頼関係追加
- ADFS要求規則設定
- (必要に応じて)ADアカウントへのグループ割り当て
環境
接続元 : オンプレミス(自宅)
- AD OS : Windows Server 2012R2 ミドルウェア : Active Directory ドメインサービス、DNSサーバー ADドメイン : fujimoto-home 利用するADアカウント : sfujimoto (所属グループ : AWS-developer、メールアドレス : [email protected])
-
ADFS OS : Windows Server 2012R2 ミドルウェア : Active Directory Federation Services
-
Client OS : Windows 7
やってみた
Active Directoryは導入済みとします。
- ADFS2.0インストール サーバーマネージャの役割と機能のインストールからActive Directory Federation Servicesを選択するだけなので、今回は手順を省略します。
-
ADFS初期設定 ADFSの初期設定を行います。
-
サービスのプロパティの指定 SSL証明書の登録、フェデレーションサービス名の指定を行います。 今回、SSL証明書はIISにおいて発行した自己署名証明書を利用しています。 フェデレーションサービス名はログインページで表示されます。
-
サービスアカウントの指定 ADFSがADとやり取りするサービスアカウントを指定します。 今回はAdministratorアカウントを利用していますが、本番環境では最小限の権限に絞ることが望ましいです。
-
データベースの指定 ADFSで利用するデータベースを指定します。 今回はデータベースを準備していないため、新規作成します。
- ADFSメタデータ取得 構成したADFSからSAML用Metadata(XMLファイル)をダウンロードします。
- AWSへIdP登録 ダウンロードしたADFSメタデータをAWSへ登録し、SAML認証可能な状態へと設定します。
-
IdP作成ウィザード IAMを操作する権限があるアカウントでAWS Management Consoleへログインします。 IAM IDプロバイダ設定画面へ遷移し、プロバイダの作成を選択します。
-
プロバイダの設定 プロバイダの設定項目を入力します。 プロバイダーのタイプ : SAML プロバイダ名 : (任意の名前) メタデータドキュメント : ダウンロードしたXMLファイル
-
設定確認 作成されたIDプロバイダを選択して、プロバイダのARNを控えておきます。 このARNにAPIを発行することでセッショントークンを発行します。
- IAM Role作成 ログインアカウントに付与したい権限のRoleを作成します。 今回の設定例ではADアカウントが所属するグループ名で付与するIAM Roleをマッピングします。ADグループ「AWS-XXXX」とIAM Role「ADFS-XXXX」がマッピングする命名規則で設定します。環境で記載したグループとマッピングしたいため、「ADFS-developer」を作成します。 IAMのロール設定画面へ遷移し、新しいロール名の設定を選択します。
-
ロールタイプの選択 今回はSAMLによるシングルサインオンを実施するため、「SAML プロバイダへのウェブシングルサインオン(WebSSO)アクセスを付与」を選択します。
-
信頼性の確立 よく分からない日本語になっていますが、「するには」に作成したIDプロバイダを選択します。 するには : fujimoto-home
-
データソースの選択 オンラインまたはローカルネットワークで公開されている証明書利用者についてのデータをインポートする : チェック フェデレーションメタデータのアドレス : https://signin.aws.amazon.com/static/saml-metadata.xml
「規則の追加」を選択し、要求規則を追加します。 今回、追加する要求規則は4つとなります。
- Windows アカウント名 -> 名前ID 要求規則テンプレート : 入力方向の要求を変換 入力方向の要求の種類 : Windows アカウント名 出力方向の要求の種類 : 名前 ID 出力方向の名前IDの形式 : 永続 ID
-
Emailアドレスの送信 要求規則テンプレート : LDAP属性を要求として送信 属性ストア : Active Directory LDAP属性 : E-Mail-Address 出力方向の要求の種類 : :https://aws.amazon.com/SAML/Attributes/RoleSessionName
-
ADアカウントのグループ取得 要求規則テンプレート : カスタム規則を使用して要求を送信 カスタム規則 :
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);
- グループ名をIAM Role名とマッピングするように変換 要求規則テンプレート : カスタム規則を使用して要求を送信 カスタム規則 :
c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-"] => issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "AWS-", "arn:aws:iam::000000000000:saml-provider/ADFS,arn:aws:iam::00000000000:role/ADFS-"));
ARNが2つあります。1つ目のARNはIDプロバイダのARN、2つ目のARNはIAM RoleのARNの途中までとなります。 これにより、グループ名からIAM Roleをマッピングすることができます。
以上で設定完了です。
動作確認
それでは動作確認しましょう。動作確認環境は別途Windows7のクライアント端末から実施します。デフォルトのADFSの認証ページとなるURLへWebブラウザからアクセスします。 https://<ADFSのURL>/adfs/ls/IdpInitiatedSignOn.aspx それでは追加した証明書利用者信頼で設定した名前を選択して、サインインします。
ドメインアカウント情報を入力して、サインインします。 「sfujimoto」アカウントは「AWS-developer」グループに所属するアカウントです。
Management Consoleが表示されましたね! AWSのアカウント情報を入力することなく、シングルサインオンできました。
ログイン情報を確認していただくと分かる通り、AssumeRoleで得た権限のIAM RoleとADアカウントに設定したメールアドレスが表示されています。このメールアドレスによって個人を特定することができます。 この情報がCloudTrailに残ることで「はじめに」で挙げた行動のトレースが可能となります。
# aws s3 cp s3://cloudtrail-ap-northeast-1-0000000000/AWSLogs/0000000000/CloudTrail/ap-northeast-1/2015/08/22/00000000000_CloudTrail_ap-northeast-1_20150822T0635Z_78Oo0xg79lwdo9qa.json.gz - |gunzip -d |jq '.' { "Records": [ (略) { "eventVersion": "1.03", "userIdentity": { "type": "AssumedRole", "principalId": "**************:[email protected]", "arn": "arn:aws:sts::00000000000:assumed-role/ADFS-developer/[email protected]", "accountId": "00000000000", "accessKeyId": "******************", "sessionContext": { "attributes": { "mfaAuthenticated": "false", "creationDate": "2015-08-22T06:29:57Z" }, "sessionIssuer": { "type": "Role", "principalId": "*******************", "arn": "arn:aws:iam::00000000000:role/ADFS-developer", "accountId": "00000000000", "userName": "ADFS-developer" } } }, "eventTime": "2015-08-22T06:32:49Z", "eventSource": "monitoring.amazonaws.com", "eventName": "DescribeAlarms", "awsRegion": "ap-northeast-1", "sourceIPAddress": "***.***.***.***", "userAgent": "console.amazonaws.com", "requestParameters": { "maxRecords": 100 }, "responseElements": null, "requestID": "9bfb57a8-4897-11e5-b579-ad52ef2b6541", "eventID": "aca02423-c8a5-4a88-a62b-8cf0d4ca062a", "eventType": "AwsApiCall", "recipientAccountId": "*********" } ] }
userIdentityのprincipalIdにメールアドレスが記録されています。
まとめ
いかがでしたでしょうか? 設定も(要求規則を除いて)シンプルで分かりやすいのではないでしょうか。 私自身、Active Directoryの管理者をしたこともなく、構築もしたことがないレベルでも、ある程度の仕組みを理解し、設定することができました。 また今回の使い方以外にも外部からのAPIの認証や、Directory Serviceとの連携等でもActive Directory資産をAWSで活用することができます。これらはまた別のエントリで紹介させていただきます。
参考サイト
Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0 ADFSを利用してAWSにシングルサインオンする方法